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ABSTRACT 


The desian,s Implementation, and evaluation of an 
adaptive scheduling algorithm for the MUNIX operating system 
is reported here. MUNIX, 9 multiprocessing version of UNIX, 
was desiqned to run on 9a dual PUP weet «6MUltiprocessior 
system. Topics covered include: a survey of adaptive: 
scheduling, laboratory equipment configuration, scheduling 
with MUNIX, benchmark testingr and non=adaptive schedulina 
changes. Conclusions and suyagestions for BOSS iinlke 


improvements are also included. 
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fee PNIROUUCTION 


In the fall of 1974, the Computer Science Group at the 
Naval Postgraduate School acauired a fairly large amount of 
computer hardware and a limited amount of software. The 
intent of acquistion was to integrate the hardware = and 
software to supnoort siqnal processing research. The hardware 
momsistea. of two PDP i1/50 commuters: mave iby Dioital 
Equipment Coroorationr one CSP 30 mrocessor made by Computer 
Siaqna] Processors eonocrateds. and various associated 
peripherals described in section II.B.e and section J1.8.3 
(see figure 3). 

An agreement with Bel] Laboratories orovided the 
software consisting of an operating system called UNIX [15). 
UNIX, as delivered, OYa note have thle capability to fully 
utilize all the system resources necessary to support signal] 
eee cs ia. As a result, several research orojects were done 
mm this®areiaa. MUNIX (7), a MR nce oe AO vers Vomeon es Ulin, 
faSmonemonrnunesoOroalectsecone.~ Note that where “the word MUNTX 
Tou Secouneaeet niiSeatnesys7 UNIX” may ber substituted. The 


Gnawa Tacemto MUNITX may easily be incorovorated inta tiNIX. 


Umezotethe Gowmlis; Of =the computer system was to handle 
real-time, timeshared, ied ead tec fh Process iAg lieleso it tewes 
founmcmttoate the scheduyiinqg alaorithm used in lity] xX coulda be 


improved for the eauinment confiaquration Pye ta Cees Clem Tn) 


1} 





excessive amount of time was being wasted Swapping users mn 
and out of core. This wasted time was a function of both the 
G@cheaguling elgerithm ena the amount of available core. 
Fiaure ft shows the amount of real timer in minutes and 
“seconds, required to run the same benchmark program (see 


hoenanemepewrth differemt amotnt’s’ of core available. 


core (K words) 


“x” 


Rice 


s \ 
00 ~ 
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fe tie 


Gees 5) ee: ee? ed = eel S Sees 5 Cm ina) 


Fireure Ts benchmark Rea) “Fime, Vs. Core Size 


Implementing a scheduling alaorithm that gave the 
interactive user faster response times and increased 
EmMeoughput was desired. SI nGeceeoeemMenoOerwotethe Computer 
Science Group was interested in adaptive schedulina, thesis 


reitica ram was "“e8ccomn!ished in this area and renporteo here. 


le 





TI. BACKGROUND INFORMATION 


A, ADAPTIVE SCHEDULING = A SURVEY 


i. General 


Scheduling alaqorithms can be placed into three 
basic classifications = round robing priorityr, and dynamic 
Or adaptive control. Algorithms based on round robin anda 
priority assignment techniques have a common characteristic: 
the processor is Switched from the process currently being 
serviced to anew process at the end of a fixed time quantum 
Siaeienmea mewhorocess is of higher priority. [fhis switching 
usually has a siaqnificant overhead and reduces’ system 
utilization. 

When an operating system is getting close to 
Saturation, the round robin scheduling aiaqorithm often fails 
to give an ddequate response time to the time-sharing user 
(16). With a priority type algorithm, processes are assianed 
priorities as they are entered into the system. The user 
supplies fhesmM OrmMalt tomamecoessary for the operating system 
£0 dSs890QM *8 Oriority to the orocess. The latormat 1oOm 
SUcmure@uGam comsSist of am esSinate of CPU timer an est imare 


o f thie amount o f core regquired, and the nNuroer of 


ie: 








input/output devices required. This information usually is 
an estimate of the maximum time or the maximum amount. of 
primary memory required. 

Adaptive control solves the oroblems of the round robin 
and priority scheduling alaorithms by giving adequate turn- 
around times to sll orocesses except those which are run gn 
the backarounds that iS, processes not in contention for 
immediate service. Several papers illustrating adaptive 
control scheduling techniques are discussed below.e 

Northouse and Fu [13] develom a scheduling alaorithm 
based on Saceptive meont ro] and clustering techniques. 
Bernstein and Sharp [2] and Sharp and Roberts (16) develoo 
an algorithm based on the orinciples “don't da anythina 
unless you have to." This avoids the system overhead of 


process"switching and swapping as much as possible. 


€. Adaptive-Control and Clustering Technique 


An adaptive controller can be referred to as a 
closed-loop or a feedback type system with the 
characteristics of the controlled process. Northouse and Fu 
(15) proposed their batch scheduler as an adaptive 
controller with three basic units: a classifier, a 
performance evaluator, and a distributor. 

" 


The classifier made an "a nriori"™ classification of al] 


iIncOomunamrous based On information supplied by the uger an 


14 





his joo, cord. A clustering algorithm Wwas@uised to estab lish 
clusters. The parameters used by the clustering alaorithm 
were: 

1) CPU time used, 

2) number of tanve drives. 

Senumberpmot i@ouUt cards. 

4) programming language. 

S) mumber of drum or disk fites. 

6) number of output paaes. 

Mochmetfort went Vive be wproner “classi ficeatvommeot 
eerste rs with the followrna final result? 

Cluster i=-meqrum CPU, larae tape file jobs 
elustter lie! araemroos 

eluster I]ll=smatl! jobs 

eluster Sivemecovum Cea, small tace filie jobs 

The performance evaluator monitored the system 
performance in specific areas and compared these evaluations 
mommces)] mememreisponses. |SpPpecifve areas “monitored inctuded 
central processor utilizisations printier traffic, drum and/or 
CaS hot tiem amas tripe drive wtilvization. tlf efficiency im a 
monitored area dropped helow a minimum acceptance tevel a 
change in the job stream was made. 

A performance index HWOSEICabrCUlatcCa and attempts were 
mage Eto F Optimize © this index FORME Cnhe wane xt subinterval 
(vYarveble lengths). The job stream was then determined 
usina this index and § linear proaramminag technique. The 
Gistpuoutor implemented the job stream that was calculated 


by the werformance evaluator. 


As yobs Were executed, their Sthtistics were wsed by 





two more components called the data collector and the data 
base updater. The updater made the system a closed loop 
system by continually updating the data base from which the 
linear proaramming function made its decisions. 

Northouse and Fur aneces ruNnAInNad two ‘simulations on 
their schedulers concluded: 


1) The scheduler was able to adapt to changing 
work loads. 


€) The job stream had definite clusters. 


3) The ODrogrammina language was an important 
parameter for classifying clusters. 


i jener oaiisit ributor reauired few calculations and 
was easily updated. 


5) Selected clusters could be forced through the 
System reducing their turnaround time. 


6) Usina a proner selection DONC yuna de 
significant impact on decreasina turnaround time. 


5. Adaptive Policy Driven Scheduler 


Peerolvey-=0r 1ven ochedu lier” Baittempts to deliver 
computational resources at a rate determined hy some tyne of 
Grituearion or Policy tunction. Be ostegmn and oharp td!l define 
PicCtiEeOOleTGy (umettToms In terms of resource units’ and “aye 
of interaction." An interaction consists of: a request from 


a user to the system, some system Servicer and a renly from 





the system back to the usere An edit command on ae timer 
sharing system 1S ‘an example of an interaction. The 
execution of a batch job is another example. 

Lica sgewotmeuicmmiIntenaet1 On mos SOmep time “t~ Ws the 
elapsed time from when the user made the request to thie 
system until time mem Resource units are a measure o f 
service received by a particular interaction. Wy is an 
MEP ueary NOn=negat ivVewet me cost ton the 1=th resource and 
Rij (t) is the number of units of the i-th resource used by 
thier jrth interactionsstsage “t". The totaill resources unitis 
Ot the j-th interaction et age "t", Rj(t), is*®eaqual to the 


sum of all the Wi times Rij(t). 
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PigquresseeskRasource Count and Policy Punctiton vs Age. 





The resource count iS a nondecreasing function of time. 
Fiaure e@ shows the resource count function for the j-th 
interaction up to age tl. A slope of zero indicates periods 
of no service while a ovositive slope indicates periods of 
resource consumptione The policy function, F(t), is shown as 
a curve. 

liner aeal of tmesschecduligafalcorithm Visi to Paes the 
terminal point of each interaction above the policy 
functione The total amount of resources required to complete 
an interaction is not uSually known in advance. Thusr the 
~milcdomitnm tt 1asetoumaintawnm Rij(t) orieatier than or equal to 
fC Dc. 

Mompnweractiome1s critical at time *t™ if Rj} (t) is less 
than F(t). Interactions are ordered according to a measure 


' Critical time is defined as: 


called "critical time.' 
tat t Con tl, 

where®tU) is!) the’ currlent time ‘and tl Ws’ the current aae of 
the interaction. tc 1s the last age of the interaction at 
Hitcimcune stawenuscrittced!. Fiaqure €@ showS Ban interaction 
OT sagem which became Criticmil at@age tc and which isestill 
ei) nC 3. 1e 

Critical time changes only when Service 18 received and 
thus only needs to he undated at that time. PHYS OF ODeEFtY 
msures that the queues Of DrOGECSSEC 4 ordered ty this 


Gquantvty Femain ordered as time proaqresses. ckiTtereo mn rocess 


receives Service it muist be relocat@®a in the queues. 





The scheduler has two queues. The “core queue" is a 

linked list of processes in main memory and the "drum queue" 

. 
is a linked list of processes not wn Main memory. Both 
queues are ordered by critical time. Processes from the 
head of the “drum queue" are transferred into main memory if 
room iS avatlable. If room 1s not ‘available for a process, 
Fr) Swapping decision iS made based on 8&8 comparison of the 
eriticeall times of the first process on the drum queue and 
the last mrocess on the core queue. 

This Scheduler reduces overhead caused by unnecessary 
Swapping by prohibiting the replacement of a orocess In core 
ee One hi tac 3 ly pirecess which iS not in core. The rules 
that make up the swapping decision are: 


1) A critical omrocess in core ¥s not eligible to he 
Swapped out (desiqned to prevent thraShina). 


ec) Processes which are inactive because they are 
awaiting communication from ae terminal are given a 
Critical time of tle). 


Seer MOonecG lt 1cCal orocess Which 1S not in main memory 
will be swapped in if room exists or tf room can be 
created hy swapping out oOrocesses with a critical time 
of t Ce). 


a) fh Critical process) which 18 not in matin memory will 

OIaolacema NOmGenrrttlcal erecess which 1S 1m §Jmsim memory. 
terns tetneamad scharn were Unable to detect 2 oepersl all ale, uSTNAa 
Phesic wconst rants. 


DaeemGSterrtUlcal Process which 1$ IN main memory and 





ready to execute 1S aiven the processor. The period of use 
LSEEeONecmLCIMermeGuamntumM ~or ~~ Until the process voluntarily 
relenquishes ity, whvehmever occurs first. the ocrocessor 15 
again dispatched after a Swapping decision is considered. 

neue Ol lcymmTUincet Ome CONtFolsethe service received by 
gach intleraction. Seoticuepolivey ) fUmctioms must ™ be set 
conservatively to avoid response problems during heavy 
loads; however, it was found that durina light load periods 
these conservative settings resulted in a2 wide range of 
service rates to similar jobs. Sharp and Roberts [16] found 
thet VoOCvune = tempor ilcy functions as the job load changed 
greatly reduced the service variance. 

Bernstein and Sharp showed that their policy driven 
scheduler was far better than a round robin scheduler in 


terms of iIimternall responsle time" measured in “seconds: 


SCHEDULER MINIMUM MEDIAN MAXIMUM 
Round Robin 4.5 Oc 102.4 
Policy7Driven ie 1./ Siete) 


taoieole koUmMG Robin VWsePolicy=Driven Scheduler 


Sharp and Roberts demonstrated that theif  adartive policy 
SEi.VoOneSecTeOiler was ~far hetter than the Static policy 


Graven SGneculer with the following reisulits: 
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RESPONSE | CPU DISC 


SCHEOULEK TIME UTILIZATION UTILIZATION 
NonwrAdaptive S lh selec. 617 YOY 
Adaptive li. fatselc. 66% “4% 


faune Sl. Nom=AcanGive Vise AOaptive Ochedu heir 


Note the differences in the maaqnitude of the response times 
in both comparisonsSe 

An adaptive policy driven scheduler as it pertains to 
the MUNIX operating system for the PDP#11/50 will be 


mScuUSScCGmIn. Getaill wee Chooter TII. 
B. LABORATORY EQUIPMENT CONFIGURATION 
1. General 


Although MUNIX is a multiprocessor operatina 
system, all testing was done with only one processor active. 
taiisee was edone’ §to control testing. Documentation of the 
laboratory eauipment configuration 1s necessary because test 
results depend on which of the two systems 1S used. Figure 
3 tishows thiel laboratory equipment and configuration. During 
the design and implementation of the adaptive scheduler, the 
operational eee nent Goms ist cameo two FOI 11750. CrU's 


(labelea A ang B) with the following equipment: 
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ec. System A 


Sek MCS memory §@450 nsec. accesls time) 
VoKwecore memory (7/50 msec. access time) 
160K CSPI memory (900 nsec. access time) 
1 DEC £450-Ceterminal 

aoucseecarttrirdages( FPKOS@eguivalent ) 
Versatec printer/plotter 

paper tape reader/punch 

Vectior Gemeral 3031 vector display terminal 
MomuewmerasrermesS@ean color ditsolayeunit 
fektromy< G04 eqisoley terminal 
Hughes Conographic console 

Data Wab liet 

EPC graphic recorder 


pe et rete eh ee te 


Se System B 


96K CMI core (850 nsec. access time) 

16K CSPI core (900 nsec. access time) 

1 DEC LASO=C tlerminal 

egw pack Gdwsk cartridaes (RK05) 

1 DEC DHi1-AC communications multiplexor connected 
to (up to 16) remote terminals 

} card reader (600 cards/min) 

1 impact printer (400 lines/min) 

e nine track magnetic tape drives 

1 seven track magnetic tape drive 


4. System A and B Differences 


The most important difference between the two 
systems 1S the amount of memory available. System B has more 
memory than system A and therefore can have more processes 
in resident core. (hus Shas wb Sianificant effect on any 
ee arnt Leocmrnomumseemsectiom 11.0.) ae oa diGitt 10m, the 


speed of the memory must alSo be considered. 


ee 
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C. SCHEDULING wITH MUNIX ON THE POP=-11/50 


MUNI X [7] is@ommultiprocesising verision of UNIX 015), «a 
general purpose, multiuserys interactive operating system 
usable on the Dieital SEauioment ~ Corporation POP=11740, 
PDP=11/45, and PDP=-11/750 computers. UNIX was developed by 
Bell Laboratories. 

In order to understand the MUNIX schedulina algorithm 
and implement a new one It was necesSary to learn Cy a high 
level programming lanquaae,. Several references were helpful 
in this endeavor [1,10,18). 

Although parts of the MUNIX operatina system have been 
documented [/7ri2}, Apmendix A will attempt to completely 


Gocument the portions related to schedulina. 


Der emNOCHMARK  TESd ING 


Benchmark testina is often used to evaluate and compare 
Ehe) pertormance of "one comonuter system relative to another. 
A benchmark program was written tO test scheduling 
alaorithms. et was necessary to use processes that 
accomplished inouts, outnutsr, Computations, and compilations. 
PEECSGUSS VON of the benchmark proqram used may he found in 


Anonendix 8. 
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E, NON*ADAPTIVE SCHEDULING CHANGES 
1. General 


Miter ‘situdying the ‘sichleduling eildqorithm used by 
MUNIX, tt was decided to make Some nonvradaptive changes 
before implementina an adaptive scheduler. Three areas were 
mMod1i+t Wed to make the algorithm more efficilient tand have a 
better aS) SwecomIStant performance wv aluations® on ~thie 
adaptive scheduler. The changes are documented in detail in 


Appendix C and summarized here. 
2. Maximum Number of Processes (NPROC) 
a. Change 
NPROC was oe esiteitice upper limit for the numbier 
of processes in the process table. The static upper limit 


was replaced by a dynamic one, thuS Saving process table 


search time. 
b. Evaluation 
The benchmark praoram (see Apnvendix B) was 


rumeadaimst the —cheduline alaorithm before wand a cer nis 


change. Four runs were mader two with a drum being used for 
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/1IMP files (temporary files), and two without. The results 
are listed in tables III and IV. Real, user, and system 
times are shown 1M minutes and seconds. Appendix B explains 
how the system calculates these times ana estimates their 
accuracy. This testing was accomplished on the "B" system 


@soec section I11.8.5.)- 


BEFORE CHANGES AFTER CHANGES 
real G220c rea] 6:00 
user e:1e user 2:00 
sys sate sys | 


Table II]. NPROC Change Evaluation with No Drum 


Before Changes After Changes 
real 43a9 real eo 
user 1:58 user 1248 
SYS | SYS wae 


Table IV. NPROC Chanae Evaluaition with Orum 


SOO GoMmilinaes Unmet 1on oCheG 


a0 Change 


Ks. deseribed wimeSe@tsronet eis and to.1.c6.tc) 


of Appendix Ay two loons im sched were shortened so na 





unnecessary code was executed. 
b. Eveailuation 


The benchmark program (see appendix B) was 
fpunioetore sana atter the changes. Severa|! runs were made 


because the statistics showed no siqnificant savinas (see 


Nable@V). hesting was) accomp! shed on the "A™ system, 


Before Changes After Changes 
real 7:08 real 7208 
user £46,.6 user -46.6 
sys eelucteg sys eee.O 


Tape Vewtooeinag Chidmoe! Evaluation 
a5 Size Check 


a. Change 


Function Sched was chdanoed to make an 
pcodtsavonal es check bleforem=suvapping qj process out of core. The 
BeeAIe Ot the incoming process hiaG to ber smaller than or equal 
Pommeene = Size sor the outgoimaq Pprodesis. ie ea imic OM 1 me 
Meecesis Men drdarestmanm a1! processes eliagihle for swanping,r 
HoOmmcmZe me Gheck« 1S Made. his task 1s accomolished usina two 


Base se Dee Anpend:ix C for a detailed exnlanation. 
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eee valwat ion 


Sevieral runs were made with 


benchmark 


program on the “A" system because af the 26 percent Savinas 


realized in real time (see Table VI). This change was 


mested one the "B" system, but 8 Sevings of only 6 percent 


was found there. The difference in savings 


the significant difference in available 


explained 


memory (the 


Solem ice ree se imes mas much user Joace) tome each says tems 


BEFORE CHANGES AFTER CHANGES 
real /#:06 real el 
userm 246.6 user a es 
SYS 2 bee 0 sys Re A 


Waible Vi. Size Check Change Evaluation 
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Pee ADAP GIVE SCHEDULER 
A. DESIGN 


The adaptive scheduler described in section JI.A,.3 


was implemented with a few minor changes. 
1. Goals 


There were two goals. that the adaptive 


scheduler attempted meet. 


a. Improve system throughput by reducing the amount of 


process swaopina Cin and out of core). 


b. Give the interactive user better resnonse time. The 
MUNIX scheduler basically gave users a round robin type of 


Service. 
ec. Desian Chanaes 


Shaep ane Roberts ti) measurea the 
CrvtnGm@mlrroyo of a mrocessS as the time from where the process 
bactmvwememcri tical Until the eurrent time (see fi9ure ee 


The iiGLementec scheduler meoasires thle critical time as the 
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Leama stonegc i nometnemoolicy fUncti’on to the resource 
count. This design chanae was made to facilitate a more 
efificvient caleulation of priorities. Sharp and Roberts 
calculated priorities on a fixed period basis. In the 
current scheme priorities are calculated whenever they are 


needed. There are two reasons for this chanae: 


1) The policy function is changed whenever the job 
(process) load reaches predetermined amounts. When the 
function 1S changedr all Jobsr both in and out of core,s have 
to have their priorities recalculated with the new policy 


mUinC t 10M. 


Cc) Depending on the -fixed time oeriod, jobs may receive 


anmeexcessive@or imsUfficient amount of resources. 


Byewerecalculating themoriorlties#on gab continuing ate 
mo special software ws needed to recalculate the priorities 
after policy functions have heen chanaed. Alsor everytime a 
echeaquligog Gecisiom Ws mader, it 1S made with the latest 


Sriomties of al isthe johns concerned. 
B. IMPLEMENTATION 
1. Process Table Control Variahles 


Met linme ese was Changoeq from a character 


variable (maximum value of tie/7) to an integer variable 
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(maximum value of 3¢767), The use of the variable was also 
changed (see Appendix A section A.1.f). Currently it is used 
as a counter for the total number of Seconds Since &@ process 
oo  osmmmlcctmanads any teletype input. It isi alisea used to 


ealcullatte the priority of the process. 


b. peflag "= was changed from a character 
variable to an integer variable hecause two additional bits 


were needed as’ special indicators. 


1) PSTM = (value of 400 octal) when set 
means that the process has received a minimum amount of 
resources in a minimum amount of time and from this point on 


Tieoe rumeStriet iy asta backqround process. 


fC) TPWAIT - (value of 1000 octal) when 
set means that this process 18 waiting for terminal input 
and will not be scheduled to run aaain until terminal Yomi uit 


has been made. 


Ce. peresr = was added as an integer variable. 
lt Ws "used to keen track of the amount of resources received 
by the individual process. The U-vector (see Apoendix A 
section A.c) of each process has two variablesr ueutime and 
uestime, that contain the same information. These variables 


Saouramovmee tiSeC@d "tor Cwo reasons: 


1) The Usvector is in core anly when the 
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process 1S core residente Priorities must be calculated 


both when the orocess 18S tn and out of core. 


2) Because of the inter-dependency of 
processes [15] (page 370), the parent Cor aqrandnrarent) 
process accumulates the resource units (ututime and utstime) 


of its childern (or grandchildern). 


This n@w variable only accumulates resource units for the 
process it is related to. ptresr 18 incremented In program 


Glloek.c 1M the same place’ls as ututime ‘and utstime. 


@s Priority Calculations 
SUG OoulI ne SCnorisec » sschedule Oriority, wals 
friuttenetoecal culate process priorities’ CseG Appendix OD). 
There were two possible areas of the operatina system that 


the priorities could be calculated. 


ae Subroutine swtch, in program slo.cr 1S 
entered each time the overatinq system changes (switches) 


Troe one PreEcess to another. 


De OoOuUDbrOULInNG schied, allio im erogram sln-.cr 
“Sementvered.  elach  €1me "a process 1s being considered tor 
SWANDING. 


A test wos run to examine the number of times the two 
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subroutines are executed relative to each other. It was 
found that swtch is executed approximately thirteen times as 
often as sched. Sched also decides which process should be 
core resident while switch decides which process Should be 
executed next. AS a result of these two observations, sched 


was menosem faS the olace to calculate priorities. 


5. Scheduling Alaorithm 


Subroutine sched (see Appendix A section B.1) 
is described with adaptive chanoes. This subroutine is a 
process with an infinite loon initiatea from function main. 
Scheao is executeodr put to sleepr awakened, and executed 
again. Sched's main. job 18 to swap processes i1n and out of 
Core. it accomplishese this task using the following 


a lqorn i t him: 


ae Set the first/second Dasis INO) Gaton 


(7soass) to a value of first pass. 


b. If there are any processes in the Swan 
file, find thier ome thet 1S tiie most critical and try to 
transfer it into core. If the Swap file is emptyr then ao 
POowus ceo "Om the RUNOUT flaq which indicates there ere no 
Processes in the swan file. When awakened ao to "he." and 
Some weocne dl sinay thy uD to a maximum of thriee different 


Tay omuoOmorinagmetmiS Omacess into core, 
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Cs I f room extistls 1m core them transfer the 


process into coree 


Geelimhoom Goes emMot exisitsmein core then sched 
NGokKISMtorenrniat, it calls Caslyy cores Easy corel ts core that 
belongs to a process that is not a system process; not 
locked, and waiting for some type of ip Out w OFF FOUCOUL. Ary 
additional constraint that applies only on the first pass is 
that the size of core needed for the INCOMING process is 
Lasiceueee) 2h on €QuUd| GommeCnIM IS iZ2G 801 core sot the outgoing 
SReCceassciem.tmeesy core 1S follimd, them the outgoing process is 
swapped out and sched goes to "ce." to continue. Sched 


repeats this until either the process can be transferred ings 


or no easy core 18 available. 


e. If no easy core is available, then sched 
searches all the processes that are in core for the one that 
has ahs (eng priority and meets the following constraints: 
the process must not be a system processy not locked, 
sleeping, and not currently being run on the other 
processor. Two additional constraints, that are made on the 


fIMSt eDOGIShOm!iVv, jome thes sige check mentioned in “d. above 
anGumamchecks tmoae. tne’ Orocess! €an hel fready to run instead of 


Sleepina. At this point there are two possible states to 


eonsider. 


IPE mlOWeSE priority process eligible 


to be swanped out 18 critical. biethis 1s Che first pass, 
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Change the first/second pass indicsetor to second pass and go 
to "dd." », or if this is the second pass and no processes are 
eligible to be transferred outer ao to sleep on the RUNIN 
flag (processeS are in the Swan file). When awakened ao to 


aoe amGlecomtinules 


2) it the’ lowest eriority procesis 
eliagible to be Swapped out 18 not critical or this is the 
second pass and a process meets the requirements in "e," 
abover then swao the indicated process out of core and go to 


Cz ane e€ontinue. 


Two additional versions of the above alaorithm were 


tcsmacgd, sand will be cdwscussed in isection IV.A. 
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IV. CONCLUSIONS AND RECOMMENDATIONS 


Ree CONCEUSRONS 


i. Critical Processes 


ae Chance 


Sharp and RKoberts' algorithm (11) did 
not Owe anyeenmocessmewhich wos critical to be®@swapped out 
of coree That same constraint was implemented by changing 


Bb. 5ee Ml and Besee-c Im section ITIl tas follows: 


beoee.! Ihemlowest priority, erocess  eliaible to be 
Swapped out WSECriIticnl. 1f t£i1SH1iSethe first passl, change 
the first/second pass indicator to second pass and go to 
nCeeemeor 5 lt — ChismmisS —the slecond pass, @o to sleep on the 


RUNIN flaq and when awakened go to “a. GOrmCcOn Wine. 


Dowco. cet tne lOWwese Priority proceiss@melligible to he 


Swapped out is not criticals then swap the process out and 


tt u“ 


Gomi ime. with Cr abovee 


This change was implemented hy only searching for processes 


Dithmomeorlrority orelater than zero. 
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be Evaluation 


Because oi the intersrelationshio 
between processese this change was able to lock all of core 
and put the operatina system into a deadlock condition. For 
exampler consider the case where both the parent and the 
child processes are critical and the parent is waiting for 
the child's termination. The child cannot terminate because 


1 is not im Gore and Cannot get into core because the 


parent is critical Cand cannot be Swapped out). 
ee. Non-Critical Processes 


de Chanage 


It was thouaht, iiiauey note try i naeto 
transfer a non-critical process into core (by Swapping 
another out), Swapping time could be saved. This chanae was 


impurememtea by addina the following gatter I11.8.5.e-. above. 


Mine ne Mm IMeCOMNinauerocess@eis mot critiaal then go to 


Sleep on the RUNIN flaq. When awakened go to “a. above EO 


GOmt InNue-. 
ree Val Uoe nen 


Mmathougnee this ehange did not cause a 


Geagioeciw Lead O Create btan UuUnsetisfactory result. Examo Ve: 
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iia ocnenimensmout TON core and hace two childern in core. The 
first child iS a compute bound job and has received a lot of 
resource units. The parent becomes critical and forces the 
non-critical child (compute bound) out. The second child 
dies, the parent 18 now waiting on the first childs but he 
G@anmot Get back into cofRe) until he 18S critical. So the 
computer has nothing to do until the child is able to aet 
mack Into core by forcina the! palrent out ‘and back into’ a new 


moc at \on-< 


3. Implemented Alaqorithm 


ae Change 


All the changes are explained in section 


Neledies tree « 
b. Evaluation 


The benchmark program was run several 


fimelis©=om the A processor with the rfresul tis listed in Tabale 


V tele 
BEFORE CHANGES PETER CHANGES 
[Col eos 1 metal gas55 ae 
* ‘Sys Beis oly. 9 ete s-: ' * isvg . STE LA a eee _ Ase ais 


Table VII. Implemented Algorithm Evaluation 
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It iS Obvious that the real time is slower. This can be 
explained in part by the amount of time spent swapping | 
processese The MUNIX scheduler solves this problem by 
Sccitdiing that a process Stay 31n core at least three seconds 
and once outs stay out at least two seconds. A similar 
effect could be accompolished with the adaptive scheduler by 
changina the process! pttime. JYhis was decided aqainst 
because the adaptive scheduler would then be a modified (Cand 


probably less efficient) MUNIX scheduler. 


4. Goals 


The coals of this thesis were not met by the 
adaptive scheduler. However, they were met in part (non- 
adaptive scheduling chanaes - section JJI].E.) by the research 


accomplished while implementing the scheduler. 


8. System thrusput was improved by reducing 


the amount of process swapping (see section I].£.4.). 


Gb. Nhe imteractive user tis not given a better 
response time, but a)!1 users are. This was accomplished by 
imoroving the efficiency O f the current scheduling 


alder itt hm. 





B. RECOMMENDATIONS 


1. WodwBetive?’ Control 


ae MUNI X 


The adaptive control schedulina 
algorithm concepts, when applied to MUNIX or UNIX will need 
iomeeemnetUlcansicgemation. UNI) usesta hierarchical process 
Structure which creates process inter-denendency problems. 
An example of the problem can be found in the "time sh 
benchmark" command sequence (Appendix 8B). The “time” command 
is the parent to the "sh" commands which is the parent to 
the “benchmark" command file. The “benchmark" command file 
will go two additional qenerations lower in all "C" compile 
commands. It 1s entirely possible to be eight or nine 
generations deep without executing any involved command 
sequences. Thus, it is a frequent occurrence that the 
currently active child will have numerous (intentionally) 
waiting ancestors which have no computational requirement 
Ginit te) the child terminates. The failure of the present 
adaptive control effort seems to stem largely from the fact 
that each process was not considered on itS own merit. 

When Seed cenit Ws waiting for a child to terminate, the 
parent should not be in competition for resource units with 


thepchila. there are two possible solutions to thts problem: 
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1) Any process that 18 in the wait state 
should not have its "“petime”™ increased. This would not allow 
a process to change priority while it 1s waiting on another 
orocesse this change would require a “status" check where 


“pDéetimer 1S incremented. 


ce) If the parent process 18 waiting on a 
childs set a status flao so that the sarent will not be put 
Mine ontent vonmwitm 1tS moen-terminated child. This change 
woulda be considered the general caser Hut 1t would reauire 


more software chanoes. 
b. Other Operatina Systems 


Implement itnq an adaptive Cont ta) 
scheculing esalaorithm with waiminiimal hierarchical istructure 
seems to he Straiaht forward.’ Sharp and Roberts (16) 


PeEeMOrteG MO SeEFIOCOUS PFoOblemS with their simolementation. 


ce Additional Research 


Additional] research should be undertaken to 
mize mphOcesSSee interactions ia) UNIX. To do this» a 
comprehensive Systems instrumentatton MNackaqe must be 
develoned. In particularr a better timimaq mechanism, a 
"complete" resource utilization accounting system, and a 


Sole aGmivemowent tracing canahility are néedéd. In Tliaqht of 


4} 





the level o f impravement Sharp and Roberts (16) report, 
additional research with adantive control and MUNIX appears 


warranted. 





APPENDIX Az: PROCESSES AND SCHEDULING 


A, PROCESS INFORMATION 


Any ittime: the word "“proceéis" iis' used in this 
appendix, tier worc “interaction from section II may be 


substituted. 


1. Process Tah lie  OFOC «hv 


This table contains the control information 
for process scheduling. Currently, the table may contain up 
to fifty active processes, each occupying a process) block 
with thirteen data elements describing it. A process 15 
assianed a process block when it 18 created and relinquishes 
it when it is deactivated. The elements and their meaninas 
are: 


ad. Pastat - fa process scheduling status with the 
following possible states: 


Gi ool wns  mOrecess has. been put to sleen 
(motrova il lavle to run). 


lea) Sovialt = thus procesSB 1S waiting for isiome type 
CtinouT7ouUtput cont lation. 


(3) SRUN = this process is ready to run. 
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(4) SIDL = tha storocess? Wise active but not in “sainy 
other status. 


CS), SZ0MB = th fs process has terminated but 
Thtogmat son in the process control block 1S 
required for other uses. 


b. p«flaaq = process status of the memory manager with 
the following possible states: 


Cro UADM= this orocess 18 loaded im main memory. 
feJMSsYo=s this orocess sSea System process. 


(3) SLOCK = this process should not be Swapped out 
of main memory and is therefore locked in. 


(4) SSWAP - this process 18S beina Swapped out of 
core. 


(SJ 3SMOR = thiis process must run on the firisit (8) 
processor. 


(6) BMDS =) thiseprocess > must fFUM On thie’ second (CA) 
SrocessSor. 


(7) Th tpt hagsused tOr prOoceSSor masking. 


(8) SBRKPT - system break points used as a debugq 
tool. 


(9) SGOING = this process is currently being run 
by some processor. 


Gn oOCoOLiaN=@ OrocesSupriortty. ~The oriorities are whole 
miner se amd mamne from -beAn Chighest) to Ile7 Clowest). 


Gomes) adeewoerocess siqnal indicator. 
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e. p&uid - the unique 10 assigned to the user that 
created this procesSSe 


ff. petime - the total time in seconds that this process 
has been in or out of core. 


Q. pettyp ~ the 1a of the terminal associated with this 
orocess. 


h. p&pid - the unioue td assianed to this process. 


1. p&ppid - the unique id assigned to the parent of 
this process. 


J. ptaddr ~- the address (memory or disk) of the first 
VancdeotstUhemoroaceiss' & Vector €desicribed hell ow). 


ke. p&size = the amount o f non~shareable core this 
process needs. 


1. pewchan ~ holds a number that can be ae channel 
agaressS Veoh sameSCEGibM indiciator. The process tis put to 
sleep or suspended with this number and it can only be 
awakened or restarted using the Same number, 


QJ 


Mere text = pointer to the shareablife portion of 
process, if it exists. 


Puy eC Ct oO fae US.e Finn) 


The system associates 1024 bytes of storaae 
witheesch user precess, celled the “vu vector". This storaaqe 
ela ema s System per "process data and the system stack for 


Gits orocess. An Wulexekon ars Tané Gai tierence Hetcween “user. and 


DroGen 1S»e aroc tn oma wavs coee.residemt while user.h is 





core resident only when the process it 1S associated with is 
core resident. The MUNIX scheduling algorithm does not use 


any elements from the u vector to make decisions. 
B, SYSTEM FUNCTIONS PERTINENT TO SCHEDULING 


Phe@seheculine tllow sine  bashe @systliem Vfillow are 


Shown im Fioure 4 {7}. 
1. sched 


This function 18 8 process with an infinite 
hOOOmininGLoveon trom TUnctlon, Maina ochied isBexecuted, put to 
EiLeepe. osee Functiom sleep below), swakened (see function 
wakeup below), and executed again. Sched's main job is to 
SWAP processes in Samd out of come. Iteaccomplishes thifs 
task using the following Boon EHhe If there are anv 
processes in the swan file (out of core)ds find the one that 
Nes beem thetestme longest and tey to transfer it into core. 
If the swap file 1S empty, then go to sleep on the RUNOUT 
flag which indicates there are no processes on the swap 
file. When the longest waiting process has been found, sched 


tmrcomUrmuol three different ways to transfer tt Imte core. 
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Figure 4. Scheduling Flow 


eit Room *%1SRSHMIn core then fro Shen the 


process in. 


b. If room does not exist in core then sched 
looms@ fer what it Calis "easy comes. Easy core is core that 
belongs to a process that 1s not a sysitem procesSr not 
locked (eligible for transfer out), and waitina for some 
Tyoemsoternout oF output. Lf feaisy core’ isi found, then that 
process vs) transferred out and "slehed®starts over by lookina 
for the process that has heen in the swap file the lonanest 
(this will be the same process that it found before), and 
Commigquecmeitne a ahn@ovess ochned repeotsS thiist umtil either 
BeCGoecessucan ber stransmmerred in or no easy core is 


Avra |i lee. 


7 





on I f No eaSy core is available then sched 
makes two more checks CO insure that the process is 
deserving enough to require another process to be 


transferred out. 


(1) If the process has not been out of 
core for more than two Seconds, sched goes to sleep on the 
RUNIN flag which indicates there is at least one process on 


the Swap Fillies 


C2) F linia the process (Cit must be 
Sitieepina OF meady —©o Fun, but not running) that has Baty in 
core the longest. If that process has not been in core at 
least two seconds then sched aqoes to sleep on the RUNIN 
flag. If it has been in more than two seconds, transfer it 
out and start over by lookinao for the process that has heen 


Gutman nwcorem@the longest and continuing wiitth “a” above. 


ee ow CG 


This function 1S invoked several places 
throughout MUNIX to accomplish the task of rescheduling the 
CPUs. Swtch searches the process table for the highest 
priority process that iS im core and ready to run on the 
Logwestamamme Cru. Ifeaasmrocess ws found it is. aiven thie CPU, 
Snepurae seine Cr 1S put Im am idle state. It stays Tho an 


ice moment | est arted agaim by an iwnterrunt. 





5. sleep 


This function 1S also invoked several places 
throughout MUNIX. It will chanqe the process' status from 
ready to sleepina or waiting depending on the value of pri. 
If pri 1s less than zeror a siaqnal cannot disturb the sleep, 
and the status 1 SEG ONnOCd eto OSL EEL. ap Weed ) SeMarehic || ekas 
than zeror the status 1S changed to SWAIT, and the process 
may be disturbed by § siaqnals. Chidin 1S Main integer that 
represents the reason the process has been placed 1n a wait 
state PoC Alte ore ooLEEP JS “After the process has been put in 


a wait state, sleep calls sSwtch to find another process tS 


FUN} 


Q., wakeup 


This function chanodsi the Batatus of all 
processes that have been out to sleep on chan from the wait 
state, Comet nhece oONUUIBState mw ready to run). If any processes 
awakened are on the swao file and sched 18 sleeping on the 
RUNOUT flag-r it 31S alSo awakened. When swtch 18S next called, 
sched will be scheduled to run (sched is the highest 
OPVOGtGvensySten ~'process ),; and an attempt will be made to 


find core for all the processes just awakened by wakeun. 


“gy 





APPENDIX B: SYSTEM BENCHMARK 


A. GENERAL 


This appendix contains information concerning the 
benchmark program used for testing and evaluatina scheduling 


changes in this thesis. 


Pee O DVO Ee ROCCE SSES 


Times for al) the individual processes can be 
found in Table VIII. The times uSed tn Table VIII are from 
the “A system (see section J1.B.2). It 1s significant to 
note that the times on the "B" system are faster because 
there iS approximately three times as much “user core" 
available. dhe benchmark consists of a series of eight 


processes (discussed below) executed from a command file. 


ipeeecn@ner 7 UIs / SYS 
Changes) the current working Girectory to the 
ACM TICNSIOe GT ted, i metiis Geese the mew working directory 1S 
f/usr/SyS. tivsommecOmnmdme —aoees mot €reate ao new process, hut 


is Girect ly executed im the shell. 


2. sh Idk 


50 





Execute tthe Command file ld. Fille’ Id loads a 


new operating system and places it in a file named “a.eout". 


our choir Gong 


See 1. above. 


seemmciGar=G COM t . Cc % 
Compile without loadina the C program named 
mcomt.c s:eeetnuS ) aorooriam  ~ecomsists of  disiga Statements, 
mith) alizatiomsa amd mo executable code. the compi lfeld object 


eademaces im a file mamed “Cconf.o". 


S. chdir /usr/bench 


Slee! 1, aboives 


Gun CG 0 ont tes tate 
Como lew the C program "'rftest.c” usina the 
experimental object=code optimizer. fhe optimized object~ 


code aoesi hin’ a fille named "a.out". 


7. bas tower <towerin >/dev/null& 
This 1S a Compute bound process that has~— an 
Vaio unt file named "“towerin" and an output file named 
Cech nuileenerne output of! lem@is ea mull device. lower 1S an 
interpretive execution of a recursive solution to the towers 
of Braman (Hanoi) problem which represents tokens as’ double 
SEC culcy Ome rOating  Poeimt mumbers. Solution is for thirteen 


Gaisks@ama three towersi. 


Bl 






Ge GChOir FusirvAsys/dmr 


See 1. above. 


7.nece rc -U tm.csé 
Compile the C program named "tm.ec" without 
loading it and with the experimental object-code optimizer. 


The resulting object-code goes in a file named "tm.o". 


ico 7 muni x. / dev/ mu) 1& 
Copy the 534,809 byte file named “/munix" to 


faites tfilemnamed “/delv7null”. 


Pee hOinwmerusr/ Sys 


Dee Sipe woeye 


12. sum /usr/sys/libl >/dev/nul1& 
Compute the checksum of the 60,390 byte file 
mamed -/issir7sys7libl” and outout the number to the file 


Nameeumraey/nu! | 


13. sum /usr/sys/lihbe >/dev/null& 


Seie 12. above. 


14. wait 
Wait until all processes started with "&" 
iNavemOCoumleted, ang reoanrt any abmormal terminations. There 
is no measurable time associated with this command if it 


Stand seem loOne< 


Wed 





All the times used in Table VIII have come from the 
time command of UNIX [18). Execution times (user and system) 
are determined by sampling the state of the system at a 60 
hz Bote C7 OU Sceomas. 2 GOUNTEF 15 kept for each type of 
time. Note that "nm" means not measurable. It is 
significant to note that the execution time can denenda on 
what kind of memory the process happens to occupy. The user 
time in MOS is approximately half of what it ts in core 
(18). This prodtnlem has been solved by running the benchmark 
program as a single user. This forces the same processes 
into the same type of core. The elapsed time (real) is 
accurate to the seconde while the CPU times (user. and 
System) are measured to the 60th of a second. It was found 
that the system times.may vary by as much as &.5 per cent, 


and the real time by Sis much tasi 6.35 per cent. 


process real user Sys 
} nm nm nm 

2 4 sd oie? 

4 nm nm nim 
ed Ce 10 lad 
5 nm nm nm 
6 57 4.e 4.0 

q 34 5028 V7 

8 nm nm nm 

g 4 } LO eo 3.4 
10 5 0.0 Oo. 
1} nm nm nm 
ke 6 U5 Pee 
13 > Ors 0.6 
14 nm nm nm 
Sum (min) 5209 ice boro 


leanles ville individual Process lines 





C. BENCHMARK PROGRAM 


The benchmark proaram consists o f ee the 
Processes mentioned in section B, above in a multiprogrammed 


mix. Time for the multipnrogrammed benchmark js: 


real 7:08 
user 46.6 
SYS Po. 0 


Table IX. benchmark Program Evaluation 


The command sequence “time sh benchmark" js used to 


Initiate processing of the benchmark, 


24 


ne 
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APPENDIX Cs NONSADAPTIVE SCHEDULING CHANGES 


A, GENERAL 


len 1.S apoendix contains detailed information 
concerning the nonwsadaptive changes made to the MUNIX (based 


on UNIX Version 5) schedulina algorithm. 


See wAS IMUM NUMBER OF PROCESSES (CNPROC) 


Pee hoande 


NO MUG@mWwoeeaecon stant detinedeyna) Datame ito. De 
Putty. That means there can be no more than fifty processes 
in the system at any one time. Twelve system functions used 
NPROC for searching the orocess table. For example: if 
function swtch was looking for the hiahest priority process, 
it looked at all entries in the process table. Normally this 
would not be considered wasteful, but the poprocess table is 
very seldom, if ever, completely full. This means there is 
time being wasted if the mrocess table does not hold fifty 
processes. Since processes are entered into the process 
table at the first available smaces a counter could be used 


to new the maximum number Ot Srocesisieis 1M the process 


wt 
si 





table. Time could be saved by searching the process table 
from thle” beqginnina to the®counterr. Tihis change was madetas 


follows: 


1. A new integer variables, nproc (lower case)r, was 
molaceid In proc.h to keep track of the last process in the 
process table. The twelve functions that used NPROC now use 


NPPOCc e 


2 Two lines of code have been added to function 
newproc Cin program slpec). The code insures that Nproc 1s 


incremented when necessary. 


3. Two lines of code have been added to function 
wait (in program sysi.c) to insure that when the last 
process in the process table terminates, Ap coe 1S 
decremented. et is not sufficent to decrement nproc by one 
in all cases. Example: The process table could have the 
first nine process’) blocks allocateds, a new process enters 
and takes block tenr process elaht and nine terminater then 
process ten terminates. If nproc was Gecremented by one, 
then all searches would look at blocks’ eight and nine 


unnecessarily. 


ewewal Uat 1on 


he benchmark proaram (see Appendix &) was 


Fupmadainsemtme scheduling alaorithm before ‘aind after this 


DO 





change. four runs were mader two with a drum being useo for 
/IMP files (tempo files)-r and two without. The results are 
listed in tables Pie andl Ver Realy wuSer, and s vist em times 
are shown in minutes and seconds. Appendix B explains’ how 
pnemeavectememecatreculates thesle —=times= -am@. estimates @their 
accuracy. This testing was accomolished on the "“"B" system 


cclke Se Ce veom..t iso «5 .) « 


BEFORE CHANGES APITER GHANGES 
rea] 6 ue real 6:00 
user e:le user 2:00 
Sys ue SYS cy 


fable ieee ROG Change tyvaluation with No Drum 


Before Changes After Chanaes 
real Gg:49 real 4:38 
user 1:58 user jelras 
SS Ah sys eel 


fobtie, P¥. NPROC Chance Evalwation with Drum 


Ceeeour iG [NRE UNG OM SCHED 


ee nance 


As descrihea Mia ttT Ones D SMUdmhe <e€. te? 


St 2ooDecm aie, sched wummecessarily loons to a point that 1s 





repetitive. The two loops were changed as follows: 


te. A Walbely “findsp” Cfind soacle for orocelss)+, was 
inserted where sched starts looking for core for the process 
it just found (the process that has been out of core the 
longest). When easy core has been found, instead of 
branching back to look for the process that has been out of 


core the longest, sched branches to findsp. 


ee A pointer, "pe", was added to the declarations 
of sched. The pointer pe was substituted for pl in the first 
EWo inistanees @antiar mo easy core 1S found. This leaves pi 
pointing to the process that has been out of core the 


longeStr Giving no neec to Search for that procesS aqain. 


Pee ey Shura t on 


The benchmark proaqram (see appendix 6) was 
run before and a fitter the chang@s. Several runs were made 
because the Statistvesm@showed no [LONG anit Savinas (see 


lable V})e téstinag was accomplished on the “A" system. 


Before Changes After Changes 
rea] es rea | 7G 
user no. Oo user S66 


Sys oi, syS Cathy 50th 


» ° 


iaoitemwy. Leoping Change Evaluation 
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Oe o1ZE CHECK 
1. Change 


In two separate places, fUnGCE VON & Sehed 
Swapped a process out of core without giving any 
SOnci@erot one as tc Reece that action created enough room 
foret hem neoming Orocess. “Many times two of threel processes 
were sSwapped out of core when only one was necessary. This 


creates a large overhead in swapping. A two pass check was 


iors tal led to circumvent this problem. 


1. BIrsK Passes Ceeer Nto See thet the process 
being swapped out of core is as large or larger than the one 


being swapped inr if nots do not Swan it cut. 


ec. Second pass - lf the first pass fails to create 
enauan room tor “the jincomina procesis, Swap eliaible 


processes out until enough room exits. 


This change was implemented using a first/second pass 
inc lGawenmeec tT SOASS)memmaving the Vialue of zero far the first 
pasis ang one for the second paisis. This indicator was "or"ed 
Vitis i z2e check —thereby using the same cod@ for hoth 


passes. 


eS 





ce. Evaluation 


Several runs were made with the benchmark 
program on the "A" system because of the 26 vercent savings 
realized in real time (see Tabte VI). This change was 31s0 
tested on the "“B" system, but a savinas of only 6 percent 
was found there. The difference in savinas 1s explained by 


the significant difference in available memory for each 


Syisit em. 

BEFORE CHANGES AFTER CHANGES 
rea ty 2 US rea] os 1d 
user :46.6 user ©45,3 
sys 162.0 Sys ie, 


Table VI. Size Check Chanae Evaluation 
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/* 
* 
k 


x / 


APPENDIX DO: PRIORITY CALCULATION SUBROUTINE 


This subroutine was written by Ronald E. Joy and 
lise Gm tenon sadomtive scneduler im November of 1975. 


wc WluGem se7 OOrameh 
fcluGge “.sr7O0rOC +h” 


/* 
x 


Tf the following variables are needed in any 


* other program, include schpori.h 


x/ 


~~ + ee eee OO 


liviueete hal 4; // slope 1 chanaes at this 
// time (seconds). 
joie S | ool C; V7 number ot 61 tis.to Ssihi ft 
yee Nett e=e*o Estope 1). 
int slope O; y7 numbereet bits to Ishi tt 
ae lett. — ss lwCslopem,), 
1me chat i 16; // vf tcehot!l or slool are 


// changed, chat! must be 
4/ Changed alisio. 


LimenGot. = tchoalkp<< "siicp! 
wav OOp rt 300; li OAC mea rouUma Or lor) t y¥ 
int minpri 7500; // \owest priority (value) 
int maxori 300; /7# max Priority (value) 
Linke Syihere te y eau) Te ax t1Me "pe TOF | by 
int mxtime 540; loa mMar time w= 9 min Gsec?) 
imt maxrfels 7200; // max resource units. this 
// value 18 = e@ minutes. 


The following code is used to set a users priority 
between ~500 and 300. A value of 0 is the least 
Grite dl priority, with ~S50Cs50eing the most 
erveical. Amy viollue over U GWs®non-critical. A 
Orocess 1S$ critical if it ha@s®not received as 
HmAaMmyeresource UmitS as dictated by the nolicy 
TUNCEION: 


6 |} 





Seneppcare) 77) schedule priority 
StrPuctOroc Anarho; 4// pointer to process that needs 


{ 


J7/@awpriority calcudated. 


reaqister Struct proc xrp; // process pointer 
register int ori; fyecalieculatec orrority 
register int resrs // resource units received 
int time; // current time of this* process 


rp = nNrp-s 

time = ro ->petimes 

resp = rorsocresr, 

if (rp->peflaa&PSTIVM ft) re->peflag&FTPWAIT) 

4// if this process 18s already a hack ground 
J// pmROCceEsSs or jt ilisi waiting for tierminal 170 


pri = bapri,; // priority = back around 
else { 
if (resr < Q) // tas’ the resource count 


// aone over S3ce/67. there 1S no chance 
// of this happenina with mxtime set to 
// \ts Current value. 


(apes bef laqu=, PSIM*fprie= bapri;} 
V7 agnet Fol { liag and priority to ha 
else t 


if (time >= mxtime) // if process has 
// been alive lonaer than mxtime 
if (resi > maxres) // Wf resource 
// count greater than maxres 
tee oct faq rol; ors & boapris) 
// s@t PSLM and pri to ba 


else 
pri = mtori; // max time priority 
else { 
if (time < tcehaq!) 7/71 fe oroce ss 


// has been alive less than tchal 
eri = resir = (time << islopi); 
else 
pri = resr ~ choti - 
CCE tite =—t chal) “<< %s'l ond)? 


if (pri > maxpri) (Forno kon yt y 
// is too larae 
or) = maxori; Vhs At 
else 
CEG ies emir) // too snall 
Ory e-em LApn 1s 77 tie i t 
} 
} 
} 
return (pri); Per etuinn@priOrity to ca) Her 
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